Subject: DLSw Version 0.16 Chapter 3 (2 of 2)

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Thu, 22 Dec 94 10:26:37 PST

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 3
X-Sun-Content-Length: 66

This is overall part 3 of 12

This is part 2 of 2 of Chapter 3

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: dlsw3b.txt
X-Sun-Content-Lines: 434
X-Sun-Content-Length: 18777

RFC XXXX      DLSw: Switch-to-Switch Protocol  December 1994

    DATA LINK ID  (14 Bytes @ Control message offset 24 decimal)
   +-----------------------------+-----------------------------+
   | Target MAC Address                                        |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | Origin MAC Address                                        |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | Origin Link SAP             | Target Link SAP             |
   +-----------------------------+-----------------------------+

   An end-to-end circuit is identified by a pair of Circuit ID's.  A
   Circuit ID is a 64 bit number that identifies the DLC circuit within a
   single DLSw.  It consists of a DLC Port ID (4 bytes), and a Data Link
   Correlator (4 bytes).  The Circuit ID must be unique in a single DLSw
   and is assigned locally.  The pair of Circuit ID's along with the Data
   Link IDs,  uniquely identify a single end-to-end circuit.  Each DLSw
   must keep a table of these Circuit ID pairs, one for the local end of
   the circuit and the other for the remote end of the circuit.  In order
   to identify which Data Link Switch originated the establishment of a
   circuit, the terms, "Origin" DLSw and "Target" DLSw, will be employed in
   this document.

    CIRCUIT ID   (8 Bytes)
   +-----------------------------+-----------------------------+
   | DLC Port ID                                               |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+
   | Data Link Correlator                                      |
   +- - - - - - - - - - - - - - -+- - - - - - - - - - - - - - -+
   |                                                           |
   +-----------------------------+-----------------------------+

   The Origin Transport ID and the Target Transport ID fields in the
   message header are used to identify the individual TCP/IP port on a Data
   Link Switch.  The values have only local significance.  However, each
   Data Link Switch is required to reflect the values contained in these
   two fields, along with the associated values for DLC Port ID and the
   Data Link Correlator, when returning a message to the other Data Link
   Switch.

   The following figure shows the use of the addressing parameters during
   the establishment of an end-to-end connection.  The CANUREACH,
   ICANREACH, and REACH_ACK message types all carry the Data Link ID,
   consisting of the MAC and Link SAP addresses associated with the two end
   stations.  The CANUREACH and ICANREACH messages are qualified by the
   SSPex flag into CANUREACH_ex, ICANREACH_ex (explorer messages) and

AIW DLSw Related Interest Group           DLSw version 0.16 [Page 14]

RFC XXXX      DLSw: Switch-to-Switch Protocol  December 1994

   CANUREACH_cs, ICANREACH_cs (circuit start).  The CANUREACH_ex is used to
   find a remote MAC and Link SAP address without establishing an SSP
   circuit.  Upon receipt of a CANUREACH_cs message, the target DLSw starts
   a data link for each port, thereby obtaining a Data Link Correlator.  If
   the target station can be reached, an ICANREACH_cs message is returned
   to the origin DLSw containing the Target Circuit ID parameter.  Upon
   receipt, the origin DLSw starts a data link and returns the Origin
   Circuit ID to the target DLSw within the REACH_ACK message.  (Note for a
   full list of message types, see section 3.5.)

   +------------+                                +------------+
   |Disconnected|                                |Disconnected|
   +------------+   CANUREACH_cs (Data Link ID)  +------------+
       ------------------------------------------------->
         ICANREACH_cs (Data Link ID, Target Circuit ID)
       <------------------------------------------------
     REACH_ACK (Data Link ID, Origin Cir ID, Target Cir ID)
       ------------------------------------------------->
   +------------+                                +------------+
   |Circuit Est.|                                |Circuit Est.|
   +------------+                                +------------+
     XIDFRAME (Data Link ID, Origin Cir ID, Target Cir ID)
       <------------------------------------------------>
      CONTACT (Data Link ID, Origin Cir ID, Target Cir ID)
       ------------------------------------------------->
     CONTACTED (Data Link ID, Origin Cir ID, Target Cir ID)
       <-------------------------------------------------
   +------------+                                +------------+
   | Connected  |                                | Connected  |
   +------------+                                +------------+
        INFOFRAME (Remote Circuit ID = Target Circuit ID)
       ------------------------------------------------->
        INFOFRAME (Remote Circuit ID = Origin Circuit ID)
       <-------------------------------------------------

   During the exchange of the XIDFRAME, CONTACT, and CONTACTED messages,
   the pair of Circuit ID parameters is included in the message format
   along with the DATA LINK ID parameter.  Once the connection has been
   established, the INFOFRAME messages are exchanged with the shorter
   header.  This header contains only the Circuit ID associated with the
   remote DLSw.  The Remote Data Link Correlator and the Remote DLC Port ID
   are set equal to the Data Link Correlator and the DLC Port ID that are
   associated with the origin or target Data Link Switch, dependent upon
   the direction of the packet.

3.3. Correlators

   The local use, and contents of the Data Link Correlator, Port ID and
   Transport ID fields in SSP messages is an implementation choice.  These
   fields have local significance only.  The values received from a partner
   DLSw must not be interpreted by the DLSw that receives them and should
   be echoed "as is" to a partner DLSw in subsequent messages.  All
   implementations must obey the following rules in this section (3.3) on

AIW DLSw Related Interest Group           DLSw version 0.16 [Page 15]

RFC XXXX      DLSw: Switch-to-Switch Protocol  December 1994

   the assignment and fixing of these correlator fields for each transport
   connection or circuit:

   The Transport ID fields are learned from the first SSP message exchanged
   with a DLSw partner (the Capabilities exchange).  This field should not
   be varied by a DLSw after the capabilities exchange and must be
   reflected to the partner DLSw in every SSP control message.

   The Target Data Link Correlator, Target Port ID and Target Transport ID
   must remain the same once the Target DLSw has sent the ICANREACH_cs for
   a given circuit.  The Origin DLSw must store the values specified in the
   ICANREACH_cs and use these on all subsequent SSP messages for this
   circuit.

   The Origin DLSw must allow these fields to vary until the ICANREACH_cs
   is received.  Each SSP message issued for a circuit must reflect the
   values specified by the Target DLSw in the last SSP message for this
   circuit received by the Origin DLSw.  Binary zero should be used if no
   such message has yet been received for a given circuit (apart from the
   Target Transport ID which will have been learnt as specified above).

   The Origin Data Link Correlator, Origin Port ID and Origin Transport ID
   must remain the same once the Origin DLSw has issued the REACH_ACK for a
   given circuit.  The Target DLSw must store the values specified in the
   REACH_ACK and use these on all subsequent SSP messages for this circuit.

   The Target DLSw must allow these fields to vary until the REACH_ACK is
   received.  Each SSP message issued for a circuit must reflect the values
   specified by the Origin DLSw in the last SSP message for this circuit
   received by the Target DLSw.  Binary zero should be used if no such
   message has yet been received for a given circuit (apart from the Origin
   Transport ID which will have been learnt as specified above).

   For the purposes of correlator exchange, explorer messages form a
   separate circuit.  Both DLSw partners must reflect the last received
   correlator values as specified above.  However correlators learned on
   explorer messages need not be carried over to a subsequent circuit setup
   attempt.  In particular, the Origin DLSw may elect to use the same
   values for the Origin Data Link Correlator and Origin Port ID when it
   issues a CANUREACH_cs after receiving an ICANREACH_ex or NETBIOS_NR_ex.
   However the Target DLSw must not assume that the CANUREACH_cs will
   specify any of the Target Data Link Correlator or Target Port ID that
   were exchanged on the explorer messages.

   Received SSP messages that require a valid Remote Circuit ID but cannot
   be associated with an existing circuit should be rejected with a
   HALT_DL_NOACK message.  This is done to prevent a situation where one
   DLSw partner has a circuit defined while the other partner does not.
   The exception would be a HALT_DL_NOACK message with an invalid Remote
   Circuit ID.  The HALT_DL_NOACK message is typically used in error
   situations where a response is not appropriate.

   The SSP messages requiring a valid Remote Circuit ID are all messages
   except the following: CANUREACH_ex, CANUREACH_cs, ICANREACH_ex,

AIW DLSw Related Interest Group           DLSw version 0.16 [Page 16]

RFC XXXX      DLSw: Switch-to-Switch Protocol  December 1994

   ICANREACH_cs, NETBIOS_NQ_cs, NETBIOS_NR_cs, DATAFRAME, NETBIOS_ANQ,
   NETBIOS_ANR, KEEPALIVE and CAP_EXCHANGE.

3.4. Largest Frame Size Field

   The Largest Frame Size (LF Size) field in the SSP Control Header is used
   to carry the LF Size bits across the DLSw connection.  This should be
   used to ensure that the two end-stations always negotiate a frame size
   to be used on a circuit that does not require the Origin and Target DLSw
   partners to re-segment frames.

   This field is valid on CANUREACH_ex, CANUREACH_cs, ICANREACH_ex,
   ICANREACH_cs, NETBIOS_NQ_ex and NETBIOS_NR_ex messages only. The
   contents of this field should be ignored on all other frames.

   Every DLSw forwarding a SSP frame to its DLSw partner must ensure that
   the contents of this frame reflect the minimum capability of the route
   to its local end-station or any limit imposed by the DLSw itself.

   The bit-wise definition of this field is as follows (bit 7 is the most
   significant bit, bit 0 is the least significant bit):

     7   6   5   4   3   2   1   0
   +-------------------------------+
   | c | r | b | b | b | e | e | e |
   +-------------------------------+

     c   .   .   .   .   .   .   .  LF Size Control flag
                                    (significant on messages
                                    from Origin to Target
                                    DLSw only)

                                    0=fail circuit if route
                                      obtained requires a
                                      smaller LF size
                                    1=don't fail the circuit
                                      but return the LF size
                                      obtained even if it is
                                      smaller

     .   r   .   .   .   .   .   .  Reserved
     .   .   b   .   .   .   .   .  Largest Frame Bit Base
     .   .   .   b   .   .   .   .  Largest Frame Bit Base
     .   .   .   .   b   .   .   .  Largest Frame Bit Base
     .   .   .   .   .   e   .   .  Largest Frame Bit Extended
     .   .   .   .   .   .   e   .  Largest Frame Bit Extended
     .   .   .   .   .   .   .   e  Largest Frame Bit Extended

             <----- LF Bits ----->

   Refer to IEEE 802.1D Standard, Annex C for encoding of Largest Frame
   base and extended bit values.

AIW DLSw Related Interest Group           DLSw version 0.16 [Page 17]

RFC XXXX      DLSw: Switch-to-Switch Protocol  December 1994

   The Origin DLSw "Size Control" flag informs a Target DLSw that chooses
   to reply to *_cs messages on the basis of cached information that it may
   safely return a smaller LF Size on the ICANREACH_cs frame if it has had
   to choose an alternative route on which to initialize the circuit.  If
   this bit is set to 1, the Origin DLSw takes responsibility for ensuring
   that the end-stations negotiate a suitable frame size for the circuit.
   If this bit is set to 0, the Target DLSw must not reply to the
   CANUREACH_cs if it cannot obtain a route to the Target end station that
   support an LF Size at least as large as that specified in the
   CANUREACH_cs frame.

AIW DLSw Related Interest Group           DLSw version 0.16 [Page 18]

RFC XXXX      DLSw: Switch-to-Switch Protocol  December 1994

3.5. Message Types

   The following table lists the protocol data units that are exchanged
   between Data Link Switches.  All values not listed are reserved for
   potential use in follow-on releases.

   Command          Description                       Type   flags/notes
   -------          --------                         ------  -----------
   CANUREACH_ex     Can U Reach Station-explorer      0x03   SSPex
   CANUREACH_cs     Can U Reach Station-circuit start 0x03
   ICANREACH_ex     I Can Reach Station-explorer      0x04   SSPex
   ICANREACH_cs     I Can Reach Station-circuit start 0x04
   REACH_ACK        Reach Acknowledgment              0x05
   DGRMFRAME        Datagram Frame                    0x06   (note 1)
   XIDFRAME         XID Frame                         0x07
   CONTACT          Contact Remote Station            0x08
   CONTACTED        Remote Station Contacted          0x09
   RESTART_DL       Restart Data Link                 0x10
   DL_RESTARTED     Data Link Restarted               0x11
   ENTER_BUSY       Enter Busy                        0x0C   (note 2)
   EXIT_BUSY        Exit Busy                         0x0D   (note 2)
   INFOFRAME        Information (I) Frame             0x0A
   HALT_DL          Halt Data Link                    0x0E
   DL_HALTED        Data Link Halted                  0x0F
   NETBIOS_NQ_ex    NETBIOS Name Query-explorer       0x12   SSPex
   NETBIOS_NQ_cs    NETBIOS Name Query-circuit setup  0x12   (note 3)
   NETBIOS_NR_ex    NETBIOS Name Recognized-explorer  0x13   SSPex
   NETBIOS_NR_cs    NETBIOS Name Recog-circuit setup  0x13   (note 3)
   DATAFRAME        Data Frame                        0x14   (note 1)
   HALT_DL_NOACK    Halt Data Link with no Ack        0x19
   NETBIOS_ANQ      NETBIOS Add Name Query            0x1A
   NETBIOS_ANR      NETBIOS Add Name Response         0x1B
   KEEPALIVE        Transport Keepalive Message       0x1D   (note 4)
   CAP_EXCHANGE     Capabilities Exchange             0x20
   IFCM             Independent Flow Control Message  0x21
   TEST_CIRCUIT_REQ Test Circuit Request              0x7A
   TEST_CIRCUIT_RSP Test Circuit Response             0x7B

   Note 1: Both the DGRMFRAME and DATAFRAME messages are used to carry
   information received by the DLC entity within UI frames.  The DGRMFRAME
   message is addressed according to a pair of Circuit IDs, while the
   DATAFRAME message is addressed according to a Data Link ID, being
   composed of a pair of MAC addresses and a pair of link SAP addresses.
   The latter is employed prior to the establishment of an end-to-end
   circuit when Circuit IDs have yet to be established or during circuit
   restart when Data Links are reset.

   Note 2: These messages are not used for the DLSw Standard but may be
   used by older DLSw implementations.  They are listed here for
   informational purposes.  These messages were added after publication of
   RFC 1434 and were deleted in this standard (adaptive pacing is now used
   instead).

AIW DLSw Related Interest Group           DLSw version 0.16 [Page 19]

RFC XXXX      DLSw: Switch-to-Switch Protocol  December 1994

   Note 3: These messages are not normally issued by a Standard DLSw, which
   uses the NB_*_ex messages as shown in section 5.4..  However if a
   Standard DLSw attempts to interoperate with older DLSw implementations,
   these messages correspond to the NETBIOS_NQ and NETBIOS_NR messages used
   in RFC1434 both to locate the resource and to setup a circuit.  This
   document does not attempt to provide a complete specification of the use
   of these messages.

   Note 4:  A KEEPALIVE message may be sent by a DLSw to a partner DLSw in
   order to verify the TCP connection (or other future SSP carrying
   protocol) is still functioning.  If received by a DLSw, this message is
   discarded and ignored.  Use of this message is optional.

   For the exchange of NetBIOS control messages, the entire DLC header is
   carried as part of the message unit.  This includes the MAC header, with
   the routing information field padded to 18 bytes, and the LLC header.
   The following message types are affected:  NETBIOS_NQ, NETBIOS_NR,
   NETBIOS_ANQ, NETBIOS_ANR, and DATAFRAME when being used by NetBIOS
   systems.  The routing information in the DLC header is not used by the
   remote Data Link Switch upon receiving the above five messages.

   Any SSP message types not defined above if received by a DLSw are to be
   ignored (i.e. no error action is to be performed).  A Data Link Switch
   should quietly drop any SSP message with a Message Type that is not
   recognized or not supported.  Receipt of such a message should not cause
   the termination of the transport connection to the message sender.

AIW DLSw Related Interest Group           DLSw version 0.16 [Page 20]